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Allocating and Retiring Special-Purpose MPLS Labels 
Abstract 


Some MPLS labels have been allocated for specific purposes. A block 
of labels (0-15) has been set aside to this end; these labels are 
commonly called "reserved labels". They will be called "special- 
purpose labels" in this document. 


As there are only 16 of these special-purpose labels, caution is 
needed in the allocation of new special-purpose labels; yet, at the 
same time, forward progress should be allowed when one is called for. 


This memo defines new procedures for the allocation and retirement of 
Special-purpose labels, as well as a method to extend the special- 
purpose label space and a description of how to handle extended 
Special-purpose labels in the data plane. Finally, this memo renames 
the IANA registry for special-purpose labels to "Special-Purpose MPLS 
Label Values" and creates a new registry called the "Extended 
Special-Purpose MPLS Label Values" registry. 


This document updates a number of previous RFCs that use the term 
"reserved label". Specifically, this document updates RFCs 3032, 
3038, 3209, 3811, 4182, 4928, 5331, 5586, 5921, 5960, 6391, 6478, and 
6790. 

Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7274. 
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Copyright Notice 


Copyright (c) 2014 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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Introduction 


The MPLS Label Stack Encoding specification [RFC3032] defined four 
special-purpose label values (0 to 3) and set aside values 4 through 
15 for future use. These labels have special significance in both 
the control and the data plane. Since then, three further values 
have been allocated (values 7, 13, and 14 in [RFC6790], [RFC5586], 
and [RFC3429], respectively), leaving nine unassigned values from the 
original space of sixteen. 


While the allocation of three out of the remaining twelve special- 
purpose label values in the space of about 12 years is not in itself 
a cause for concern, the scarcity of special-purpose labels is. 
Furthermore, many of the special-purpose labels require special 
processing by forwarding hardware, changes to which are often 
expensive and sometimes impossible. Thus, documenting a newly 
allocated special-purpose label value is important. 


This memo outlines some of the issues in allocating and retiring 
Special-purpose label values and defines mechanisms to address these. 
This memo also extends the space of special-purpose labels. 


1. Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


Two new acronyms are introduced: 


XL Extension Label. A label that indicates that an extended 
Special-purpose label follows. 


ESPL Extended Special-Purpose Label. A special-purpose label that 
is placed in the label stack after the Extension Label. The 
combination of XL and ESPL might be regarded as a new form of 
"compound label" comprising more than one consecutive entry in 
the label stack. 


Questions 


In re-appraising MPLS special-purpose labels, the following questions 
come to mind: 


1. What allocation policies should be applied by IANA for the 
allocation of special-purpose labels? Should Early Allocation 
[RFC7120] be allowed? Should there be labels for experimental 
use or private use [RFC5226]? 
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2. What documentation is required for special-purpose labels 
allocated henceforth? 


3. Should a special-purpose label ever be retired? What criteria 
are relevant here? Can a retired special-purpose label ever be 
re-allocated for a different purpose? What procedures and time 
frames are appropriate? 


4. The special-purpose label value of 3 (the "Implicit NULL Label" 
[RFC3032]) is only used in signaling, never in the data plane. 
Could it (and should it) be used in the data plane? If so, how 
and for what purpose? 


5. What is a feasible mechanism to extend the space of special- 
purpose labels should this become necessary? 


6. Should extended special-purpose labels be used for load 
balancing? 


3. Answers 


This section provides answers to the questions posed in the previous 
section. 


A. Allocation of special-purpose MPLS labels is via "Standards 
Action". 


B. The IANA registry will be renamed "Special-Purpose MPLS Label 
Values". 


C. Early allocation may be allowed on a case-by-case basis. 


D. The current space of 16 special-purpose labels is too small 
for setting aside values for experimental or private use. 
However, the "Extended Special-Purpose MPLS Label Values" 
registry created by this document has enough space, and this 
document defines a range for experimental use. 


2. A Standards Track RFC must accompany a request for allocation of 
Standards Action special-purpose labels, as per [RFC5226]. 


3. The retirement of a special-purpose MPLS label value must follow 
a strict and well-documented process. This is necessary since we 
must avoid orphaning the use of this label value in existing 
deployments. This process is detailed in Section 3.2. 
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4. For now, the use of the "Implicit NULL Label" (value 3) in the 
data plane will not be allowed. If this decision is revisited 
later, an accompanying Standards Track RFC that details the use 
of the label, a discussion of possible sources of confusion 
between signaling and data plane, and mitigation thereof shall be 
required. 


5. A special-purpose label (the "Extension Label", XL, value 15) is 
set aside for the purpose of extending the space of special- 


purpose labels. Further details are described in Section 3.1. 

6. [RFC6790] says that special-purpose labels MUST NOT be used for 
load balancing. The same logic applies to extended special- 
purpose labels (ESPLs). Thus, this document specifies that ESPLs 


MUST NOT be used for load balancing. It is noted that existing 
implementations would violate this, as they do not recognize XL 
as anything other than a single special-purpose label and will 
not expect an ESPL to follow. The consequence is that if ESPLs 
are used in some packets of a flow, these packets may be 
delivered on different paths and so could be re-ordered. 
However, it is important to specify the correct behavior for 
future implementations, hence the use of "MUST NOT". 


A further question that needed to be settled in this regard was 
whether a "regular" special-purpose label retains its meaning if it 
follows the XL. The answer to this question is provided in 

Section 3.1. 


3.1. Extended Special-Purpose MPLS Label Values 


The XL MUST be followed by another label L (and thus MUST have the 


bottom-of-stack bit clear). L MUST be interpreted as an ESPL and 
interpreted as defined in a new registry created by this document 
(see Section 5). Whether or not L has the bottom-of-stack bit set 


depends on whether other labels follow L. The XL only assigns 
special meaning to L. A label after L (if any) is parsed as usual 
and thus may be a regular label or a special-purpose label; if the 
latter, it may be the XL and thus followed by another ESPL. 


The label value 15 is set aside as the XL as shown in Section 5. 


Values 0-15 of the "Extended Special-Purpose MPLS Label Values" 
registry are set aside as reserved. Furthermore, values 0-6 and 8-15 
MUST NOT appear in the data plane following an XL; an LSR processing 
a packet with an XL at the top of the label stack followed by a label 
with value 0-6 or 8-15 MUST drop the packet. 
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Label 7 (when received) retains its meaning as Entropy Label 
Indicator (ELI) whether a regular special-purpose label or an ESPL; 
this is because of backwards compatibility with existing implemented 
and deployed code and hardware that looks for the ELI without 
verifying if the previous label is XL or not. However, when an LSR 
inserts an entropy label, it MUST insert the ELI as a regular 
Special-purpose label, not as an ESPL. 


3.1.1. Forwarding Packets with Extended Special-Purpose Labels 


If an LSR encounters the XL at the top of stack and it doesn't 
understand extension labels, it MUST drop the packet as specified for 
the handling of an invalid incoming label according to [RFC3031]. If 
an LSR encounters an ESPL at the top of stack (after the XL) that it 
does not understand, it MUST drop the packet, again following the 
same procedure. In either case, the LSR MAY log the event, but such 
logging MUST be rate-limited. 


An LSR SHOULD NOT make forwarding decisions on labels not at the top 
of stack. For load-balancing decisions, see Answer 6 in Section 3. 


3.1.2. Choosing a New Special-Purpose Label 


When allocating a new special-purpose label, protocol designers 
should consider whether they could use an extended special-purpose 
label. Doing so would help to preserve the scarce resources of 
"normal" special-purpose labels for use in cases where minimizing the 
Size of the label stack is particularly important. 


3.2. Process for Retiring Special-Purpose Labels 


While the following process is defined for the sake of completeness, 
note that retiring special-purpose labels is difficult. It is 
recommended that this process be used sparingly. 


a. A label value that has been assigned from the "Special-Purpose 
MPLS Label Values" registry may be deprecated by IETF consensus 
with review by the MPLS working group (or designated experts if 
the working group or a successor does not exist). An RFC with at 
least Informational status is required. 


The RFC will direct IANA to mark the label value as "deprecated" 
in the registry but will not release it at this stage. 


Deprecating means that no further specifications using the 
deprecated value will be documented. 
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At the same time, this is an indication to vendors not to include 
the deprecated value in new implementations and to operators to 
avoid including it in new deployments. 


b. Twelve months after the RFC deprecating the label value is 
published, an IETF-wide survey may be conducted to determine if 
the deprecated label value is still in use. If the survey 
indicates that the deprecated label value is in use, the survey 
may be repeated after an additional 6 months. 


C. If the survey indicates that a deprecated label value is not in 
use, 24 months after the RFC that deprecated the label value was 
published, publication may be requested of an IETF Standards 
Track Internet-Draft that retires the deprecated label value. 
This document will request that IANA release the label value for 
future use and assignment. 


4. Updated RFCs 


The following RFCs contain references to the term "reserved labels": 


o [RFC3032] ("MPLS Label Stack Encoding") 

o [RFC3038] ("VCID Notification over ATM link for LDP") 

o [RFC3209] ("RSVP-TE: Extensions to RSVP for LSP Tunnels") 

o [RFC3811] ("Definitions of Textual Conventions (TCs) for 
Multiprotocol Label Switching (MPLS) Management") 

o [RFC4182] ("Removing a Restriction on the use of MPLS Explicit 
NULL") 

o [RFC4928] ("Avoiding Equal Cost Multipath Treatment in MPLS 
Networks") 


o [RFC5331] ("MPLS Upstream Label Assignment and Context-Specific 
Label Space") 


o [RFC5586] ("MPLS Generic Associated Channel") 

fe) [RFC5921] ("A Framework for MPLS in Transport Networks") 

o [RFC5960] ("MPLS Transport Profile Data Plane Architecture") 

o [RFC6391] ("Flow-Aware Transport of Pseudowires over an MPLS 
Packet Switched Network") 

o [RFC6478] ("Pseudowire Status for Static Pseudowires") 

o [RFC6790] ("MPLS Entropy Labels") 


All such references should be read as "special-purpose labels". 
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5. IANA Considerations 


IANA has made the following changes and additions to its registration 
of MPLS labels. 


1. Changed the name of the "Multiprotocol Label Switching 
Architecture (MPLS) Label Values" registry to "Special-Purpose 
MPLS Label Values". 


2. Changed the allocation policy for the "Special-Purpose MPLS Label 
Values" registry to Standards Action. 


3. Assigned value 15 from the "Special-Purpose MPLS Label Values" 
registry, naming it the "Extension Label" and citing this 
document as the reference. 


4. Created a new registry called the "Extended Special-Purpose MPLS 
Label Values" registry. The registration procedure is Standards 
Action, and the ranges for this registry are as shown in Table 1 
(using terminology from [RFC5226]). Early allocation following 
the policy defined in [RFC7120] is allowed only for those values 
assigned by Standards Action. 


R--------------------- 4------------------2-2----------2------2---------- t 
| Range | Allocation Policy 
4+--------------------- +---------------------- ---- - 5 5 5 = + 
| 0- 15 | Reserved. Never to be made available for | 
| | allocation. | 
| 16 - 239 | Unassigned 
| 240 - 255 | Reserved for Experimental Use 

256 = 1048575 Reserved. Not to be made available for 

allocation without a new Standards Track 
| | RFC to define an allocation policy. 
4+—--------------------- +---------------------- -- = + 
Table 1 
6. Security Considerations 


This document does not make a large change to the operation of the 
MPLS data plane, and security considerations are largely unchanged 
from those specified in the MPLS Architecture [RFC3031] and in the 
MPLS and GMPLS Security Framework [RFC5920]. 
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8. 


8. 


However, it should be noted that increasing the label stack can cause 
packet fragmentation and may also make packets unprocessable by some 
implementations. This document provides a protocol-legal way to 
increase the label stack through the insertion of additional 
(XL,ESPL) pairs at a greater rate than insertion of single "rogue" 
labels. This might provide a way to attack some nodes in a network 
that can only process label stacks of a certain size without 
violating the protocol rules. 


This document also describes events that may cause an LSR to issue 
event logs at a per-packet rate. It is critically important that 
implementations rate-limit such logs. 
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